The modern cable network has evolved a long way from its humble beginnings. In 1948, the first community antenna system delivered television signals over twin-lead strung from house to house. In 1950, a coax system was built in which the coax cable was strung on utility poles. These systems were intended to solve reception problems caused by weak signals (rural areas) or by ghosting from multiple reflected signals (urban areas). In the seventies, communications satellites breathed new life into the cable industry by providing access to programming not otherwise available in the cable operator's service area.
Until recently, the cable network was still predominantly a vehicle for delivering entertainment. With the advent of the Internet and the rise in demand for broadband two-way access, the cable industry began to seek ways of utilizing its existing plant.
A major problem for a cable operator desiring to provide two-way digital service was the configuration of its network. Designed for one-way delivery of broadcast signals, the existing cable network topology was optimized for downstream (toward the subscriber) only service. New equipment would have to be added to the network to provide two-way communication. To reduce the cost of this equipment and to simplify the upgrade of the broadcast cable for two-way digital traffic, standards were developed for a variety of new cable-based services. The first of these standards, the Data Over Cable System Interface Standard (DOCSIS), was released in 1998. DOCSIS establishes standards for cable modems and supporting equipment.
PacketCable™ is another Cable Labs®-led project to define a common platform to deliver advanced realtime multimedia services over a two-way cable plant. The PacketCable architecture defines a platform to deliver Internet Protocol services over the DOCSIS access network. The first service defined for this platform is Voice-over-Internet Protocol (VoIP). The core set of PacketCable 1.0 specifications describe how to move the basic functions that are typically consolidated on a single, expensive Class 5 central office switch onto several general-purpose servers, which leads to a low-cost, highly flexible, scalable, distributed architecture. The PacketCable architecture is flexible and can be extended to support advanced real-time multimedia services, such as multi-person online gaming, video-conferencing, and others.
On Apr. 5, 2002, the CableHome™ 1.0 standard was released. (“CableHome” is a trademark of Cable Television Labs, Inc.) The CableHome standard establishes a common architecture for the provision of new services to residential customers, simplifies the management the home network, and protects copyrighted information from being diverted to other uses.
One common attribute of each of these standards is the requirement that certain devices connected to the cable network be “provisioned” before those devices may be operated on the network. Provisioning involves a process by which a “provisionable device” is initialized, authenticated, registered, and configured to operate with a cable network. A provisionable network device receives a boot file as part of the provisioning process. By way of illustration and not as a limitation, a provisionable network device may be a DOCSIS-compliant cable modem (DCCM) or a media terminal adapter (MTA).
Referring to FIG. 1, the provisioning of a DCCM with a boot file is illustrated. Each time a DCCM is powered-on or reset, it must be initialized 100 through a series of “handshakes” and transfers of data between itself and a cable modem termination system (CMTS) at the cable headend. Following initialization, the DCCM is then authenticated 120 to confirm that the DCCM is entitled to receive service. The next provisioning step is registration 130, where the DCCM is configured as an Internet device. During this process, the DCCM synchronizes its clock with that of the CMTS and obtains an Internet protocol (IP) address from a Dynamic Host Configuration Protocol (DHCP) server. The DHCP server also provides the DCCM the network address of a Trivial File Transfer Protocol (TFTP) server and where a device boot file for that modem can be found and downloaded. The DCCM requests its device boot file 140 by the sending the TFTP a request message comprising a device boot file filename. Upon receipt of the boot file, the DCCM sends a registration request (REG-REQ) to the CMTS. This REG-REQ includes the current service identification (SID), IP address, operational parameters, upstream and downstream channel IDs, time stamps, and other configuration settings. If the information is accepted, the CMTS responds with a new SID and completes the registration process.
Under the PacketCable specifications, VoIP services are provide via an MTA. The MTA comprises the interface to a physical voice device, a network interface, CODECs, and all signaling and encapsulation functions required for VoIP transport, class features signaling, and QoS signaling. The MTA is provisioned so as to obtain its IP configuration required for basic network connectivity, announce itself to the network, and download of its boot file data from its provisioning server. Provisioning includes adding, deleting and modifying subscriber services on one or more endpoints of the embedded-MTA.
The MTA device is required by the PacketCable specification to verify the authenticity of the configuration file it downloads from the server. Further, the back office applications is require support a “flow-through” provisioning mechanism that synchronizes all device provisioning information on the MTA with the appropriate back office databases and servers. Synchronization is required in the event that provisioning information needs to be recovered in order to re-initialize the device. At a minimum, the back office and the MTA must synchronize customer records and the MTA configuration file.
In a DOCSIS environment, the device boot file typically comprises device attributes that are expressed in type-length-value (TLV) format and information necessary for the DOCSIS device to operate on the cable network to which it is connected. By way of illustration, for a DCCM the attributes identified by the DOCSIS standard include the maximum upstream and downstream data rates (based on the service level to which the customer has subscribed), the number of devices supported by the DCCM that require IP addresses, and information necessary to identify and authenticate the DCCM to the cable network. The device boot file is received by the DCCM in binary format. The DCCM uses the device boot file to populate device attributes with specific values.
Typically, DOCSIS device boot files are stored in a file library on a server. A device boot file is created for each possible configuration of a provisionable network device. The permutations of the various service levels coupled with other subscriber-specific elements makes management of this library a significant task. Additionally, large networks must maintain multiple file library servers, requiring that all servers be updated with changes to the file library. In order to establish a new configuration for a device, even for a single customer, a new device boot file must be added to the file library and populated to all of the file library servers.
As previously described, devices used to provide other services require device boot files. For example, voice over Internet protocol (VoIP) service meeting the PacketCable standard is supported by a media terminal adapter (MTA) that connects to the DCCM. The MTA has a device boot file specified by the PacketCable standard. Additionally, because the MTA requires its own network (IP) address, the DCCM device boot file must be modified to reflect that the DCCM supports two addressable devices (the computer to which it is connected and the MTA).
As more data services are made available to subscribers, the number of permutations of possible configurations increases requiring the cable operator to maintain larger configuration libraries. The size of the configuration library not only burdens the cable operation from a network management perspective, but also limits its ability to provide services that are customized at the subscriber level.
Not all configurable equipment used in a cable network is subject to industry standards. Routers, for example, are configured using conventions established by their manufacturers. In a large network, a service provider typically maintains routers having custom configuration settings for large commercial customers. Maintaining and changing these configuration settings manually, especially in networks utilizing non-standardized equipment of multiple manufacturers, is time consuming and subject to error.
In “On-The-Fly TFTP Server Specification,” by Bruce Bahlmann (http://www.birds-eye.net/technical_archive/otf-tftp.htm) (herein, “Bahlmann”), problems associated with using TFTP with a large number of unique or shared device boot files are identified. Bahlmann proposes that the device boot file “could be built on-the-fly (preferably in memory) bypassing problems of scaling local storage, updates, and redundancy for configuration files needed to support large numbers of subnets (greater than 50).” Bahlmann also describes a means of structuring a boot file request to convey specific device parameters using the file path and file name.
Bahlmann does not identify how an “On-the-Fly” TFTP server converts the device parameters into a device configuration file or how the files within the “On-the-Fly” TFTP server would be constructed and maintained. Additionally, while Bahlmann discusses configuration of provisionable network devices other than cable modems using a Lightweight Directory Access Protocol (LDAP), the structure of an LDAP schema to accomplish this objective is not specified.
What would be useful is a system and a method for dynamically generating and providing a device boot file to a provisionable network device. The particular device attributes and values of those attributes in the device boot file would be selected based on a boot file identifier included in a boot file request.